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(54) Security policy applied to common data security architecture 



(57) An improved architecture is provided, based 
upon the prior art common data security architecture, 
with the modification of adding in a generic trust policy 
library (217) at an add-in security modules layer (215) 
and a policy interpreter (224) at a common security serv- 
ices manager layer (202), so that individual users may 
provide sets of trust policies in the form of a trust policy 
description file (223), which uses a generic policy de- 
scription language provided by the architecture. The ar- 



chitecture provides a generic method of incorporating 
trust policies into a computing platform in a manner 
which avoids a prior art problem of the semantics of trust 
policies which are hard-coded in prior art trust policy 
modules (117). The architecture also improves manage- 
ment flexibility. In the present disclosure, a generic pol- 
icy description language is provided, which enables dif- 
ferent users to define the semantics of a plurality of trust 
policies. 



Layered Services [ 



< 

to 

CM 
O) 
00 



CL 
LU 



Integrity Services | Po , iey mierpreler p 2 



Security Contexts 



> Elective > 
Module ! Module I 

Manager [Manager^ 21 



Jj SPI | J TPI | ^ ACI 1 A CU 1 Jj PL' 1 J t EMI ; 

>rw' n.rt 01 1 1 ' ' 1 om 



209 210 



213 214" 




1 EP1 1 

Description 

Field of the Invention 

[0001 ] The present invention relates to improvements 
in security architecture of computer platforms, and par- 
ticularly although not exclusively, to improvements in 
policy-based security management in the Common Da- 
ta Security Architecture (CDSA). 

Background to the Invention 

[0002] With the wide acceptance of the Internet and 
the World Wide Web, it has become much easier for us- 
ers to access various resources such as documents, di- 
rectories, databases, web pages and services using 
Common Gateway Interfaces (CGIs) or Servlets over 
the Internet. This has given rise to some serious security 
issues relating to access of data on individual computing 
resources such as authentication of users, integrity 
checking of users platforms, privacy and security of da- 
ta, and authorization to access data. 
[0003] Known prior art security systems include Mi- 
crosoft's Cryptographic API (CryptoAPI), which is de- 
pendent upon the Internet Explorer 3.x or above and 
Windows NT 4.0, and the known Sun Microsystems' 
Java Cryptography Extension (JCE) is similarly platform 
dependent being based upon a Java platfotm. Each of 
these prior art security systems are dependent upon a 
proprietary operating system or platform. The Intel's pri- 
or art Common Data Security Architecture (CDSA) is ap- 
plicable over a wide range of computer platforms and 
operating systems. The Common Data Security Archi- 
tecture provides a flexible and extensible framework al- 
lowing software and hardware produced by independ- 
ent vendors to provide added-in security services in a 
computer platform environment. The Common Data Se- 
curity Architecture is an open and industry accepted 
standard, supporting interoperability between plat- 
forms, platform independence and a comprehensive set 
of security services. Since the Open Group adopted its 
initial specification in December 1 997, CDSA has been 
widely supported. Referring to Fig. 1 herein, the current 
prior art CDSA version 2.0 has the following 4 layers: 

• An applications layer 1 00 

• A layered services layer 1 01 , having a set of secu- 
rity services protocols, a language interface-adapt- 
er and tools 

• A Common Security Services Manager (CSSM) lay- 
er 102 

• An add-in security modules layer 1 03, having facility 
for a plurality of add-in security modules such as a 
Cryptographic Service Provider (CSP) modules, 
Certificate Library (CL) modules, Trust Policy (TP) 
modules, Authorization Computation (AC) modules 
and Data Storage Library (DL) modules. 
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[0004] The application layer 1 00 has a set of security 
applications, which are contained in the layer; the lay- 
ered service layer 101 comprises typically a set of se- 
curity services protocols such as HTTPS, S/MIME, SSL, 

5 or SET; the CSSM layer 1 02 contains a set of manage- 
ment modules 104-109, a set of integrity services for 
checking the integrity of modules, a manager of security 
contexts for security services, and a set of interfaces 
110-115; and the add-in security modules layer 103 has 

io a set of user configurable security services modules 
11 6-1 21 which may be proprietary and vendor-specific, 
and which can be accessed by the CSSM via the inter- 
faces 110-115 in the CSSM layer 102. 
[0005] The security services management modules 

is 104-109 comprise a Cryptographic Service Provider 
manager 104, a Trust Policy module manager 105; an 
Authorization Computation module manager 106; a 
Certificate Library module manager 1 07; a Data Storage 
Library module manager 108; and an elective module 

20 manager 109. 

[0006] A limitation with the known Common Data Se- 
curity Architecture occurs where a set of trust policies 
are to be implemented in a computer platform. Trust in 
a computing platform is a particularly important issue 

25 where computer platforms are used for electronic com- 
merce, and handle items such as credit card numbers, 
automated trading programs and general commercial 
transactions. Trust policies comprisea set of rules which 
are followed by a computer platform to determine a level 

30 of confidence in the integrity of a computer platform 
which a user of the computer platform and/or other com- 
puter platforms interacting with the computer platform 
may have. For example, a user or a third party comput- 
ing entity interacting with a first computing entity must 

35 have a degree of confidence that the first computing en- 
tity has not been compromised by a virus, or has not 
been tampered with, such that the computer platform 
cannot be trusted. 

[0007] In the known Common Data Security Architec- 

*o ture, trust policies may be implemented by provision of 
a trust policy services module 117. However, these are 
proprietary and vendor specific. Each different vendor 
provides his own trust policy module 1 1 7, written in a set 
of semantics which are specific to that vendor. The se- 

*5 mantics of a known trust policy module are completely 
hard-coded by its module developer. The trust policy 
module users must understand the semantics used by 
the vendor-specific trust policy module 117, so that for 
each trusted policy module 117, modification needs to 

so be made to the trust policy module because of the dif- 
ferent semantics used between different vendors. Once 
a trust policy module 117 is released, users are unable 
to add new trust policies or modify existing ones without 
using the vendor-specific semantics. From the user's 

» perspective, this is not ideal, since the user may want 
their own specific trust policies to be enforced in their 
application domains instead of those policies provided 
and hard-coded by the vendor. The security infrastruc- 
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ture provided by the prior art CDSA is neither truly ge- 
neric nor flexible for security and/or trust management. 
[0008] In the prior art CDSA security architecture, for 
each trusted policy module, the semantics of a set of 
trust policies are determined by an individual developer. 
Different prior art trust policy modules written by differ- 
ent developers have different sets of semantics. A user 
may wish to change the trust policies to fit more closely 
the user's business organization. Because the trust pol- 
icy module uses non-generic semantics, the user must 
return to the developer who wrote the trust policy mod- 
ule in order to have those changes made using the prior 
art security system. 

Summary of the Invention 

[0009] One object of the present invention is to pro- 
vide an improved Common Data Security Architecture 
(CDSA), which overcomes the problem of trust and se- 
curity policy management and the problem of usage of 
different semantic sets used and hard-coded in different 
vendor-specific trust policies for a computer platform. 
[0010] A second object of the present invention is to 
provide a security architecture in which individual users 
may specify their own policies to be enforced in the us- 
er's individual application domains. 
[0011] A third object of the present invention istopro- 
vide an improved security architecture in which individ- 
ual users may specify their own policies to be enforced, 
within any layer of the CDSA security architecture. 
[0012] Another object of the present invention is to 
provide an architecture, which allows users to define 
their own policies using tools provided by the architec- 
ture. 

[001 3] According to an aspect of the present invention 
there is provided a security architecture for a computer 
platform comprising at least one data processor and at 
least one memory means said architecture comprising: 

an applications layer (200) for containing a plurality 
of user security applications; 

a layered services layer (201) for containing a plu- 
rality of security service protocols, a language inter- 
face-adapter, and tools for policy and model author- 
ing or the like; 

a security services management layer (202) com- 
prising a plurality of security services management 
means (203-208), a set of integrity services, a man- 
ager of security contexts for security services, a pol- 
icy interpreter (224), and a plurality of interfaces 
(209-214) via which the CSSM can access the add- 
in security services modules (216-221) described 
below; and 

a function modules layer (21 5) capable of accepting 
a plurality of add-in security services modules 



(21 6-221 ) implementing a standard set of functions; 

characterized in that said security architecture 
comprises; 

5 

a Generic Trust Policy Library (termed herein GT- 
PL, 217) having all the standard APIs of a prior art 
trust policy library (1 1 7) and some extra APIs which 
deal with Trusted Policy Description File (termed 
10 herein TPDF, 223); 

a trust policy description file (223) comprising a set 
of domain-specific trust policies written in a policy 
description language common to said security ar- 
»s chitecture; and 

a policy interpreter (224), said policy interpreter op- 
erating to interpret a set of trust policies contained 
in said trust policy description file (223). 

20 

[001 4] Preferably at least one of said plurality of said 
services management means (205-208) is provided 
with a corresponding respective Policy Description File 
(PDF) determining the policies with which said at least 

25 one security services management means operates. 
[001 5] Preferably at least one of said plurality of said 
add-in security services modules (21 6, 21 8-221 ) is pro- 
vided with a corresponding respective Policy Descrip- 
tion File (PDF) determining the policies with which said 

30 at least one add-in security services modules operates. 
[001 6] Preferably the architecture is characterized by 
further comprising a set of policy and model authoring 
tools (400), allowing a userto create a policy description 
file implementing a set of user specif ied policies for con- 

35 trolling said computer platform. 

[0017] Said policy description language preferably 
comprises a known PROLOG language. 
[0018] Preferably said policy interpreter (510) com- 
prises a PROLOG inference engine. 

40 [0019] Said security services management layer 
(502) is provided with its own policy description file (520) 
for implementing policies in that layer. 
[0020] Said applications layer (500) may be provided 
with an applications layer policy description file (54) for 

*s determining policies to be implemented to said applica- 
tions layer. 

[0021] Said layered services layer (501 ) may be pro- 
vided with a layered services policy description file (506) 
for determining policies followed by said layered servic- 
50 es layer. 

Brief Description of the Drawings 

[0022] For a better understanding of the invention and 
55 to show how the same may be carried into effect, there 
will now be described by way of example only, specific 
embodiments, methods and processes according to the 
present invention with reference to the accompanying 
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drawings in which: 

Fig. 1 illustrates schematically the prior art 4-layer 
Common Data Security Architecture version 2.0; 

Fig. 2 illustrates schematically an improved Com- 
mon Data Security Architecture according to a first 
specific prototype implementation of the present in- 
vention; 

Fig. 3 illustrates schematically an example of an au- 
thorization policy, which is described in a trust policy 
description file created by a user for attachment to 
the Common Data Security Architecture according 
to the specific implementation of the present inven- 
tion; 

Fig. 4 illustrates schematically a data flow diagram 
for usage of the improved Common Data Security 
Architecture of Fig. 2 herein; and 

Fig. 5 illustrates schematically a second improved 
Common Data Security Architecture according to a 
second specific embodiment of the present inven- 
tion. 

Detailed Description of the Best Mode for Carrying 
Out the Invention 

[0023] There will now be described by way of example 
the best mode contemplated by the inventors for carry- 
ing out the invention. In the following description numer- 
ous specific details are set forth in order to provide a 
thorough understanding of the present invention. It will 
be apparent however, to one skilled in the art, that the 
present invention may be practiced without limitation to 
these specific details. In other instances, well known 
methods and structures have not been described in de- 
tail so as not to unnecessarily obscure the present in- 
vention. 

[0024] Referring to Fig. 2 herein, there is illustrated 
schematically a security architecture according to a first 
specific prototype implementation of the present inven- 
tion. The security architecture is based upon an im- 
provement to the known Common Data Security Archi- 
tecture version 1 .2, and using the known Netscape Di- 
rectory Server, version 4.0, both of which are compatible 
with a Hewlett Packard HP-UX 11 .0 operating system. 
The security architecture comprises an application layer 
200 in which a set of security applications are contained; 
a layered services layer 201 comprising a set of security 
services protocols which may include: HTTPS.S/MIME, 
SSL or SET; a language interface-adapter, tools 400 for 
policy and model authoring or the like; a Common Se- 
curity Services Manager (CSSM) layer 202 containing: 
a set of security management modules 203-208; a set 
of integrity service for checking the integrity of modules, 
a manager of security contexts for security services, a 



policy interpreter 224, and a set of interfaces 209-214; 
an add-in security services modules layer 21 5 compris- 
ing a set of user configurable security services modules 
21 6-221 , which may be proprietary and vendor-specific 

s containing a set of standard APIs, and which communi- 
cates with the CSSM via the interfaces 209-214. In the 
Common Security Services Management (CSSM) layer 
202, there is an Application Programming Interface 
(API) for interfacing between the application layer 200, 

io and the CSSM layer 202. 

[0025] The security management modules include a 
Cryptographic Service Provider (CSP) manager 203, a 
Trust Policy (TP) module manager 204, an Authorization 
Computation (AC) module manager 205, a Certificate 

is Library (CL) module manager 206, a Data Storage Li- 
brary (DL) module manager 207, and an elective mod- 
ule manger 208. 

[0026] The security architecture includes in the add- 
in security modules layer 215 a generic trust policy li- 
20 brary 217, which communicates through trust policy in- 
terface 210 and operates based upon the policies de- 
scribed in a trust policy description file 223. The policy 
interpreter 224 communicates with a generic trust policy 
library 21 7. 

25 [0027] The external trust policy description file 223 is 
specific to an application domain and may be created 
by a user using policy and model authoring tools 400. 
The semantics of each user's trust policy is completely 
defined by the external trust policy description file 223 

30 of that user. 

[0028] The combination of the generic trust policy li- 
brary 217 and one specific trust policy description file 
223 replaces the prior art trust policy module 1 1 7 in the 
known Common Data Security Architecture. Because 

35 the trust policy library 21 7 is generic, the prior art trust 
policy library 117, which is non-generic and specific to 
a prior art trust policy module developer, can be re- 
placed by the trust policy description file 223. 
[0029] The generic trust policy library 217 provides a 

40 set of module management services forthe attachment/ 
detachment of the trust policy description file 223 to/ 
from the CSSM. After a trust policy description file 223 
has been created on a system, it can be attached by the 
Common Security Services Manager (CSSM) layer 202 

*s and will be used by a set of trust policy services which 
are provided by the generic trust policy library 21 7 in the 
add-in security modules layer 215. 
[0030] Policies contained in the trust policy descrip- 
tion file 223 are implemented by a policy interpreter224, 

50 which comprises an inference engine. The inference en- 
gine can reason whether a policy statement is true or 
false. In each API of the generic trust policy library 21 7, 
a call is made to the policy interpreter 224, to see wheth- 
er the API can perform a particular function, each time 

55 such a function is attempted. For each particular API of 
the generic trust policy library 21 7, there is an associat- 
ed trust policy in the usertrust policy description file 223. 
This is interpreted by the policy interpreter 224 each 
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time an operation is attempted to be carried out. For ex- 
ample, if it is required to revoke a certificate, prior to im- 
plementing that revocation, the relevant API in the ge- 
neric trust policy library 21 7 used for revoking a certifi- 
cate would make a procedural call to the policy inter- 
preter 224, which would then interpret the policies in the 
trust policy description file 223 to see whether the re- 
voker can be trusted to revoke the certificate. The trust 
policy description file 223 may require thatthe user have 
a digital certificate issued by a trusted Certificate Au- 
thority (CA), e.g. Baltimore, Entrust or similar before it 
trusts the user to revoke a particular certificate. If a user 
has a digital certificate certified by Baltimore and Balti- 
more is a trusted CA, then the user will be trusted to 
revoke a certificate. 

[0031] A trust policy may be 'if a user has a digital cer- 
tificate cross-certified by at least two trusted Certificate 
Authorities (CAs), then the user can be trusted to revoke 
the certificates'. A different user may implement a differ- 
ent trust policy as follows 'if the user has a digital certif- 
icate certified by one of the trusted CAs, then the user 
is trusted to revoke the certificates'. These two trust pol- 
icies can be implemented by two different users using 
the same architecture according to the best mode here- 
in, by each user having different trust policy description 
files 223, but using the same policy interpreter 224 and 
generic trust policy library 21 7 provided by the architec- 
ture described herein. 

[0032] In the best mode herein, the policy interpreter 
224 and the generic trust policy library 217 are devel- 
oped once, and any changes to a user's trust policies 
are made by a user's changes to its trust policy descrip- 
tion file 223, using the policy and model authoring tools 
400. 

[0033] The policy description language defines a lan- 
guage for setting security policies. Known prior art se- 
curity policy description languages are either too specif- 
ic or too complicated for a non-programmer to use. 
There is a problem in designing a language that is both 
simple and expressive. Conventional programming lan- 
guages may be used within the generic trust policy li- 
brary 217, but the policy description language must 
have at least several of the following features. 



The policy description language is easy to use so 
that writing a policy should be as easy as describing 
what the policy is. 

The language should have good programmability. 
The language should be simple yet expressive 
enough to support writing a variety of policies. 
The language should be capable of specifying both 
security policies and domain specific trust policies. 
The language should support writing of a set of pol- 
icy templates. Policy templates comprise pre-set 
policies that are more succinct than instantiated pol- 
icies. The language should support writing of poli- 
cies having variables. 

The language should have the feature of reasona- 



bly. For example, answering the question 'is the 
user trusted to perform an operation of some re- 
source' needs to be reasoned about, if a trust rela- 
tionship can be derivable from a set of trust policies 
stored in the trust policy description file. Further- 
more, checking for policy conflicts requires an ele- 
ment of reasoning supported by the policy descrip- 
tion language. 

The language should be capable of refinement. Be- 
cause policy development is process of converting 
a high-level policy specification to a machine under- 
standable code, support of incremental policy pro- 
totyping and refinement should be a feature of the 
policy description language. 
The language should have a unified mechanism. 
Policies, credentials and trust relationships should 
be represented and processed in a unified manner, 
rather than being dealt with separately. 

In the best mode herein, the prior art program- 
ming language PROLOG (PROgramming in LOGic) 
is used for the policy description language. PRO- 
LOG is suitable for use as a language for specifying 
security policies due to its following characteristics. 
PROLOG is declarative. A rule in PROLOG defines 
a relationship between several objects. A security 
policy can be described as a rule in PROLOG. Fur- 
thermore, specifying a trust policy in PROLOG is 
almost as simple as describing what the trust rela- 
tionship is. 

In PROLOG, rules can contain variables so that the 
PROLOG language supports writing policy tem- 
plates. 

PROLOG is capable of reasoning from a set of rules 
supporting both policy evaluation and policy conflict 
detection. 

Data structures in PROLOG are uniformly ex- 
. pressed structures. Therefore, all security objects 
can be represented in a unified manner, thus sim- 
plifying their processing. 

PROLOG is a productive modeling language sup- 
porting both incremental policy writing and policy re- 
finement. 

PROLOG also provides a procedural interpretation, 
so that actions can be performed when necessary. 
PROLOG is based on Horn Clauses, which are a 
subset of the First Order Logic (FOL) that provides 
a solid mathematical foundation for general policy 
:e checking. 



[0034] In a prototype best mode implementation 
based on HP-UX 1 1 .0, the PROLOG language is adopt- 
ed as a final policy representation language, and a 
shared library is produced to function as a policy inter- 
preter. It has been observed that writing domain specific 
policies needs to model a system and an organization's 
business process using model authoring tools 400. 
[0035] Within applications, a user first calls a Com- 
mon Security Services Manager (CSSM) Application 
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Programming Interface (API), and then asks the Com- 
mon Security Services Manager to attach itself to the 
generic trust policy library 21 7, which can be done dur- 
ing the CSSM initialization. The generic trust policy li- 
brary 21 7 supports a PassThrough API , which can eval- 
uate a query, based on a set of policies. In functions de- 
fining each of other API's of a standard trust policy mod- 
ule 117, the Pass Through function is called first to en- 
force the polices associated with the particular API. In 
this way, both the add-in security modules and the Com- 
mon Security Services Manager (CSSM) are capable of 
enforcing their own security policies by calling the ge- 
neric trust policy library PassThrough API. This is a sig- 
nificant advantage over the original prior art Common 
Data Security Architecture (CDSA) framework. 
[0036] There will now be described an example of a 
policy stored in the form of a PROLOG statement in a 
users' trust policy description file 223. 
[0037] Referring to Fig. 3 herein, there is defined an 
example of a authorization policy stating that a bank ac- 
count owner (U) can transfer an amount P pounds Ster- 
ling from his account A to his other bank account B, if 
the amount P is less than £1 0,000 and less than the cur- 
rent balance of the account A. In the rule shown in Fig. 
3, the account number A, account number B, amount P 
and the balance (Balance) of account A are logical var- 
iables, which are only valid within the described rule. 
[0038] In the example of Fig. 3, a method is used to 
retrieve external information about a bank account. If the 
statement 

balance_otaccount (Balance, A) 

is evaluated as true, the logical variable Balance 
will be unified to the real balance of the bank account A. 
Furthermore, we assume the relationship 
Owner_of_account (U,A) has also been defined in a 
model. 

[0039] When a user wants to transfer money between 
its two bank accounts A, B, this can be done if the above 
policy is evaluated as true. Otherwise, the user is not 
trusted to transfer the money. 
[0040] In the above example, the policy as illustrated 
in Fig. 3 is stored in a trust policy description file 223 
created by a service provider, and is interpreted by the 
policy interpreter 224. The generic trust policy library 
217 performs the function of the attachment/detach- 
ment of the trust policy description file 223 to/from the 
CSSM. 

[0041] Referring to Fig. 4 herein, there is illustrated 
schematically a mechanism for enforcement of policies 
in the architecture according to the best mode of the 
present invention. In order to make use of the architec- 
ture, a user needs to provide a set of trust policies in a 
trust policy description file 223, which is provided by the 
user. The generic trust policy library 21 7 is pre-deter- 
mined and is created once for the add-in security serv- 
ices layer 215. This simplifies the development of the 
prior art trust policy modules 117. There are provided 
within the layered services layer 501 a set of policy and 
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model authoring tools 400 enabling the user to develop 
the Trust Policy Description File (TPDF). The generic 
trust policy library 21 7 is separate from the policy inter- 
preter 224. The semantics of a trust policy is completely 

s defined by its corresponding trust policy description file 
223 created by the user using the policy and model au- 
thoring tools 400. Because the trust policy description 
file 223 has been created using a common policy de- 
scription language, the trust policy description file is al- 

io ready in a generic format understandable by the archi- 
tecture, and transferable to another computer platform 
having the same architecture. As illustrated in Fig. 4, 
trust policies may also be retrieved from a data storage 
device 401 , to which they may have been pre-written. 

'5 [0042] Referring to Fig. 5 herein, there is illustrated 
schematically a second specific implementation accord- 
ing to the present invention. The architecture of the sec- 
ond specific implementation is based on that as de- 
scribed previously with respect to the first specific im- 

20 plementation. The architecture comprises an applica- 
tions layer 500, a layered services layer 501 , a Common 
Security Services Manager (CSSM) layer 502, and an 
add-in security services modules layer 503. In the ap- 
plications layer 500, there is provision for a plurality of 

25 security applications 504, and an application policy de- 
scription file 540 containing a set of user specified pol- 
icies applicable to the applications domain. In the lay- 
ered services layer 501 , there are provided a plurality of 
layered services 505 as described herein before, and 

30 additionally a layered services policy description file 506 
containing a set of policies applicable to the services 
contained in the layered service layer 501 . In the Com- 
mon Security Services Manager (CSSM) layer 502,' 
there is provided a set of management modules, a set 

35 of integrity services, a security contexts manager, a pol- 
icy interpreter 51 0, tools for policy and model authoring 
or the like, interfaces 521 -526 via which CSSM commu- 
nicates with add-in security modules 527-532 as de- 
scribed herein before, and a CSSM policy description 

*o file 520 comprising policies applicable to the operation 
of the CSSM layer 502. In the add-in security modules 
503, there are provided CSP modules 527, one generic 
trust policy library 528 and one or more trust policy de- 
scription files 534, AC modules 529, CL modules 530, 

45 DL modules 531 , and elective modules 532 for provision 
of new services which can be elected and specified by 
a user. Furthermore, add-in security modules 527, 
529-532 can also be extended by their respective policy 
description files 535-539. 

so [0043] Management modules comprise a Crypto- 
graphic Service Provider (CSP) manager 507 and addi- 
tionally a CSP manager policy description file 508 con- 
taining policies applicable to the CSP manager; a Trust 
Policy (TP) module manager 509 and additionally a TP 

55 manager policy description file 511 containing policies 
applicable to the TP manager; an Authorization Compu- 
tation (AC) modules manager 512 and additionally an 
AC manager policy description file 513 containing a set 
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of policies applicable to the AC module manager; a Cer- 
tificate Library (CL) module manager 51 4 and addition- 
ally a CL manager policy description file 515 containing 
policies applicable to the CL module manager; a Data 
Storage Library (DL) module manager51 6 and addition- 
ally a DL manager policy description file 51 7 containing 
policies applicable to the DL module manager; an elec- 
tive module manager 518 and additionally an elective 
module manager policy description file 519 containing 
policies applicable to the management of the elective 
modules. 

[0044] Security policies in each layer in the architec- 
ture are implemented by individual policy description 
files, which may be defined by a user or a vendor. 
[0045] Each module manager within the Common Se- 
curity Services Manager (CSSM) layer 502 may there- 
fore have its own set of policies, which can be module 
manager developer defined using tools as described 
with reference to Fig. 2 herein in a language common 
to the architecture. At each level, the user has control 
over the security policies applied in each layer, by set- 
ting the policies in that layer using the tool set provided 
within the architecture. Additionally, within individual 
add-in security modules themselves, for example the 
data storage library 531 , a user may also create a spe- 
cific policy description file 538 for controlling access to 
the data within a data store 533. An example policy can 
be as follows: 'a user of an application is not allowed to 
store private key data into a local file system based data 
storage'. This policy may be stored in a policy descrip- 
tion file 538 associated with the data storage library 531 . 
Another policy may be 'if a user wishes to access policy 
data stored in a data storage device, then the user must 
authenticate itself to the data storage device'. 
[0046] Each policy description file is interpreted by the 
single policy interpreter 51 0, which is provided within the 
Common Security Services Manager (CSSM) layer 502. 
Additionally, the CSSM layer itself has a policy descrip- 
tion file 520 whereby a user can describe policies with 
which the CSSM operates, using the common tools set 
provided within the layered services layer 501 as herein 
described with reference to Fig. 2. For example, the 
CSSM may implement its own policy stored in a CSSM 
specific policy description file 520 as follows: The 
CSSM can only attach itself to security modules which 
have been signed by those module developers who 
have digital certificates issued by the CSSM vendor'. 
[0047] There is provided both a Dynamic Link Library 
(DLL) on Windows NT 4.0 and a shared library on the 
HP-UX 11.0 of the policy interpreter 510, so that the 
Common Security Services Manager and all the add-in 
security modules can enforce their own policies by call- 
ing the policy interpreter directly rather than by calling 
the generic trust policy library PassThrough API. One 
advantage of this solution is its high efficiency. In addi- 
tion to this, there can be no need for a trust policy module 
manager 509, because the generic trust policy library 
528 can become part of the Common Security Services 



Manager layer 502. However, from the user's perspec- 
tive and for legacy prior art CDSA applications, the in- 
terface should be backwards compatible. Therefore, it 
is worth providing CDSA with both a shared library and 
s an add-in security module of the generic trust policy li- 
brary 528. 

[0048] Various of the interfaces in the Common Secu- 
rity Services Manager layer, in the Cryptographic Serv- 
ice Provider module, Certificate Library module, and Da- 
10 ta Storage Library module can be policy-based. Exam- 
ples of these are as follows: 

• Cryptographic Service Provider (CSP): private key 
storage in a CSP may enforce a policy that the CSP 

'5 must not reveal key material unless it has been 
cryptographically protected. 

• A directory-based Data Storage Library (DL): to re- 
trieve security policies stored in the directory, users 
need to be authenticated by the directory server us- 

20 ing their credentials. 

• Common Security Services Manager(CSSM) layer, 
before the CSSM attaches itself to a Cryptographic 
Service Provider (CSP) module, it must verify the 
signatures on the CSP module. 

25 

[0049] The elective module 532 is reserved for a fu- 
ture electable use. The elective module may be used for 
incorporation of a key recovery modules or a user au- 
thentication service module. 

30 [0050] The integrity services in the CSSM layer 502 
check the integrity of each add-in module and the CSSM 
itself. Each of the add-in security modules 527-532 must 
be verified based on their signatures signed by module 
developers Each module has a digital certificate, which 

35 has been signed by its developer, and incorporated into 
the module, the certificate being trusted by the CSSM 
vendor. 

[0051] As well as providing integrity services, the 
CSSM also provides security context management. For 

to example, where different algorithms are used to sign 
and/or encrypt data, which can be achieved on a item 
by item basis, with data items using different security 
contexts for data signing and/or data encryption per- 
formed by the CSP. A user can use different CSPs, 

& which may be of different manufacturers. 

[0052] Another function of the CSSM layer is module 
management. Modules may be attached to or detached 
from the CSSM, which is managed by the CSSM layer. 
Policies governing the attachment and detachment of 

so modules can be CSSM vendor specified in the CSSM 
policy description file 520. The layered services layer 
may also include its policy description file 506 governing 
the security services protocols, language interface 
adapter for languages such as Java and C++, and tools. 

55 [0053] As well as policies having being applied to the 
application layer 500, the layered services layer 501 and 
the CSSM layer 502, users may define their own secu- 
rity and trust policies at the add-in security modules lay- 
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er503 by incorporating individual user-written policy de- 
scription files into each of the Cryptographic Service 
Provider (CSP) modules 527, the Authorization Compu- 
tation (AC) module 529, the Certificate Library (CL) 
module 530, the Data Storage Library (DL) modules 
531 , and the elective service modules 532. 
[0054] The user may define his own trust policies in 
the user's policy description file. The trust policy descrip- 
tion file 534 stores policies describing a set of domain 
specific trust policies, which determine whether a com- 
puter can be trusted to perform certain operations. For 
example committing a user to a financial transaction. In 
the best mode, using the same generic trust policy li- 
brary 528, different users can each specify their own 
trust policy description files 534, describing their own 
trust policies. 

[0055] An example of a policy stored in the CSP policy 
description file 535, within a CSP module 527 may be 
'the private key of a user must never be exposed to the 
CSSM or the rest of the security architecture of a com- 
puter platform, unless it has been cryptographically pro- 
tected. 



Claims 

1 . A security architecture for a computer platform com- 
prising at least one data processor and at least one 
memory means said architecture comprising: 

an applications layer (200) for containing a plu- 
rality of user security applications; 

a layered services layer (201 ) for containing a 
plurality of security services protocols; 

a language interface adapter, and tools for pol- 
icy and model authoring or the like; 

a common security services manager (CSSM) 
layer (202) comprising a plurality of security 
services management means (203-208), a set 
of integrity services, a policy interpreter, a man- 
ager of security contexts, and a plurality of in- 
terfaces (209-214) for interfacing with add-in 
security modules (216-221); and 

an add-in security modules layer(215) capable 
of accepting a plurality of add-in security mod- 
ules (216-221) implementing a set of standard 
security services; 

characterized in that said architecture com- 
prises; 

a generic trust policy library (217) supporting a 
set of standard trust policy Application Pro- 
gramming Interfaces (APIs) and some func- 



tions dealing with trust policy description files; 

a trust policy description file (223) containing a 
set of domain-specific trust policies written in a 
5 policy language common to said architecture; 

and 

a policy interpreter (224), said policy interpreter 
operating to interpret a set of policies contained 
io in said policy description file. 

2. The architecture as claimed in claim 1 , character- 
ized in that at least one of said plurality of said man- 
agement means (203-208) is provided with a corre- 

»s sponding respective policy description file deter- 
mining the policies with which said at least one man- 
agement means operates. 

3. The architecture as claimed in any one of the pre- 
20 ceding claims, characterized by further comprising 

a set of policy and model authoring tools (400), al- 
lowing a user to create said policy description file 
implementing a set of user specified domain-spe- 
cific policies for controlling said computer platform. 

4. The architecture as claimed in any one of the pre- 
ceding claims characterized in that said policy de- 
scription language comprises a known PROLOG 
language. 

30 

5. The architecture as claimed in any one of the pre- 
ceding claims characterized in that said policy inter- 
preter comprises a PROLOG inference engine. 

35 6. The architecture as claimed in any one of the pre- 
ceding claims characterized in that said common 
security services manager layer (502) is provided 
with its own policy description file (520) for imple- 
menting policies in that layer. 

40 

7. The architecture as claimed in any one of the pre- 
ceding claims characterized in that said applica- 
tions layer (500) is provided with an applications 
layer policy description file (540) for determining 

<5 policies to be implemented in said applications lay- 
er. 

8. The architecture as claimed in any one of the pre- 
ceding claims characterized in that said layered 

so services layer (50 1 ) is provided with a layered serv- 
ices layer policy description file (506) for determin- 
ing policies followed by said layered services layer. 

9. The architecture as claimed in any one of the pre- 
ss ceding claims characterized in that at least one of 

said plurality of add-in security modules (216, 
218-221) is provided with a corresponding respec- 
tive policy description file determining the policies 
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with which at least one add-in security module op- 
erates. 
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